FIG. 1 shows a Universal Mobile Telephony System (UMTS). The UMTS network comprises a Core Network (CN) 100 that is connectable to other networks such as the Internet, other mobile networks e.g. GSM systems and fixed telephony networks denoted POTS in FIG. 1. The CN 100 is connected to a plurality of Radio Network Controllers (RNCs) 102 belonging to the UMTS Radio Access Network (UTRAN). The respective RNC 102 controls a plurality of Node-Bs 104 comprising one or more base stations 106. Each base station covers an area, i.e. a cell and is arranged to serve the mobile terminals within said cell. Finally, the mobile terminals 108, also referred to as User Equipments (UE) are connected to one or more base stations 104.
In the UTRAN a user equipment (UE) can be in one of several RRC states depending on the user activity. These states comprise Idle Mode, URA_PCH, CELL_PCH, CELL_FACH and CELL_DCH, listed in order of increasing user activity.
In Cell_PCH and URA_PCH, no communication is possible and minimum radio and battery resources are consumed. When the UE has data to send, it needs to transmit a Cell Update message to the UTRAN, indicating that uplink data is available. When UTRAN has data to send to a UE in CELL_PCH or URA_PCH it needs to send a paging message to the UE, and the UE responds with a Cell Update message to indicate in which cell it is located.
In CELL_FACH, communication is possible but with low data rate and high round trip time due to the properties of the shared channel used in this state. A UE in this state consumes more radio resources compared to CELL_PCH/URA_PCH but less resources than compared to CELL_DCH.
In CELL_DCH the UE has a dedicated channel available which implies that communication with high data rate and low round trip time is possible.
The CELL_DCH state provides the best user performance in terms of data rate and delay, but also consumes the most resources, e.g. in terms of power and codes. Thus it may be necessary to move users to lower states when the data transmission stops. A typical case for many applications is that data transmission occurs so seldom that the UE is in CELL_PCH or URA_PCH state when a data burst transmission starts. This implies that the delay to move from CELL_PCH/URA_PCH to CELL_DCH needs to be minimized, in order to have a good user performance. If the application transmits small data objects the time to change state will have a more significant impact on the user performance than the data rate on DCH. A Push-to-Talk service is one example, where rather small objects are transmitted rather infrequently. This service could start with a burst from the network side if the terminal in CELL PCH/URA PCH is the receiver of the talk burst. In this the delay for transmitting a data object (including transition to CELL_DCH) is to a large extent determined by the time to move from CELL/URA_PCH to CELL_DCH.
When a UE in CELL/URA_PCH needs to transmit uplink data, the typical signalling sequence is shown in FIG. 2. In step 1, the UE sends a Cell Update message to indicate that it has uplink data available to transmit. In step 2, UTRAN responds with transmitting a Cell Update Confirm message which acknowledges the Cell Update Message and orders the UE to enter CELL_FACH state, where data transmission is possible. In step 3, The UE transmits a UTRAN Mobility Information Confirm message to acknowledge the Cell Update Confirm message. It is now possible for the UE to transmit data on RACH, i.e. it is in CELL_FACH state. If the available amount of data, which is denoted the Traffic Volume in 3GPP specifications, is above a configured threshold the UE transmits a Measurement Report to inform UTRAN about the available amount of data (step 4). When UTRAN receives the Measurement Report it can decide to move the UE to CELL_DCH since the RACH has very limited performance. UTRAN therefore sends a Radio Bearer Reconfiguration message in step 5 to move the UE to CELL_DCH. The UE responds with a Radio Bearer Reconfiguration Confirm message in step 6, which acknowledges the received message. Now the UE has entered CELL_DCH and can transmit data on the DCH.
Correspondingly, FIG. 3 depicts the typical signalling sequence when a UE in CELL/URA_PCH needs to receive downlink data. The UE receives in step 1 a paging message. The UE shall answer such a paging message. In step 2, the UE answers the paging message by sending a Cell Update message to indicate that it has received the paging message. In step 3, UTRAN responds with transmitting a Cell Update Confirm message which acknowledges the Cell Update Message and order the UE to enter CELL_FACH state, where data transmission is possible. In step 4, The UE transmits a UTRAN Mobility Information Confirm message to acknowledge the Cell Update Confirm message. It is now possible for the UE to receive data on FACH (i.e. it is in CELL_FACH state). If the available amount of data buffered for this UE in the RNC (denoted Traffic Volume in 3GPP specifications) is high enough as evaluated by UTRAN, it can decide to move the UE to CELL_DCH since the FACH has very limited performance. UTRAN therefore sends a Radio Bearer Reconfiguration message in step 5 to move the UE to CELL_DCH. The UE responds with a Radio Bearer Reconfiguration Complete message in step 6, which acknowledges the received message. Now the UE has entered CELL_DCH and can receive data on the DCH.
Another alternative for moving a UE from CELL/URA_PCH to CELL_DCH is depicted by help of FIG. 4. According to this alternative it would also be possible with the current 3GPP specifications to order the UE to CELL_DCH directly in the Cell Update Confirm message. This would result in a signalling sequence as shown in FIG. 4. In this alternative, the UTRAN orders the UE to CELL_DCH already in the Cell Update Confirm Message in step 2. The UE responds with a Radio Bearer Reconfiguration Complete message in step 3 and can then start to transmit data on DCH.
Correspondingly, FIG. 5 shows an alternative signalling sequence for moving a UE from CELL/URA_PCH to CELL_DCH in case of a UTRAN initiated transmission. Here, the UTRAN orders the UE to CELL_DCH already in the Cell Update Confirm Message in step 3. The UE responds with a Radio Bearer Reconfiguration Complete message in step 4 and can then start to receive data on DCH.
The alternative signalling sequence for UE initiated transmission described above in FIG. 3 is much faster than the normal sequence. In practice the time to move from CELL/URA_PCH to CELL_DCH can be more than halved. However, this alternative sequence also implies the problem that the UTRAN has no information about the amount of data that the UE has available for transmission. The Cell Update message only contains a cause value indicating the cause for the cell update, in this case “uplink data transmission”.
This means that the UTRAN has to move the UE to CELL_DCH without knowing if this is necessary or even desired. For small data objects the transmission time on CELL_FACH is smaller than on CELL_DCH due to the relatively large delay to setup the DCH channel. Thus it would in fact reduce the user performance if the UE is moved to CELL_DCH when the available amount of data is small. Given that it consumes network resources to move users to DCH, these resources are wasted if the UE is moved to DCH when there is no need.
Turning back to FIG. 5, the alternative signaling sequence for UTRAN initiated transmission described in said figure could be seen as somewhat faster than the sequence in FIG. 3. However, since UTRAN have all the knowledge about the downlink buffers for this UE and know already when sending the Paging type 1 message that the UE should be moved to CELL_DCH state, there is no need to have the UE go via the CELL_FACH state before continuing the transition to CELL_DCH state. Performing Cell update procedure in CELL_FACH state (step 2 and 3 in FIG. 5) takes a substantial amount of time since the messages are sent on contention based common channels used by several users. By removing these steps in CELL_FACH state the sequence could therefore be made even faster if the UE transits directly from CELL_PCH/URA_PCH to CELL_DCH. This faster sequence is currently not supported in the 3GPP specifications.